Computer systems that provide sufficient throughput for high-volume real time processing of transactions, such as order book transactions in financial market systems, pose challenges for system architects and software engineers. For example, in electronic financial markets, a matching engine performs order book processing of a received transaction or order. In particular, an order is received and the matching engine determines the price at which the order is to be matched (for example, sold or purchased). The order book is a list of orders that records the interests of buyers and sellers for a particular financial instrument, such as a symbol being traded, a commodity, a derivative or the like (security). The matching engine uses the order book to match and to fulfill the incoming orders. These matched orders become trades when matched. Each market may have its own matching rules and order types which determine how they are matched.
One set of important related constraints is that the order book transactions must be performed linearly (sequentially) and may need to update a common resource, for example, memory resources, thus temporarily blocking the resource. As orders are inserted, updated or removed into an order book, a memory space implementing the order book is locked until a change is complete. Such atomization of transactions may guarantee that data is inserted, updated or removed properly and completely, and that the action is not overridden by another transaction.
A further wrinkle is that a credit profile must often be applied to control the amount of liability, risk or exposure of a user, such as an institution, individual or other party that submits orders for traders. The credit profile may include one or more credit limits, for example, for an investor, such as an institution, fund manager, or other investing or trading party, that are set by the investor party or by another institution, such as a market, exchange, bourse, sector or venue administration, and are used by the matching engines to control risk or exposure for the institution for the given market, industry or regional sector, or the like. A credit limit may be set using multiple market rules. It can be set based on a per security basis, on a per market basis, on a per sector, industry or other sub-market or investment strategy basis, or the like or based on a combination of the foregoing. Further, a credit limit may be set across a platform or a venue encompassing multiple market types.
A first approach for implementing a credit profile is that each security has its own credit limits, which are not shared across securities or with other markets within the venue. FIG. 2 illustrates such a centralized scenario, in which the matching engine itself can run one or more order books. Each security requires an order book, and the matching engine itself maintains and checks the credit limits internally.
Such a matching engine would have an interface that receives both orders for the order book and credit limit updates for the institution. When an order is submitted to the matching engine, the matching engine may determine whether it is accepted. That is, during the order book matching process, the credit limit is checked to determine whether the order can be traded. This process is done internally within the matching engine itself. If based on the currently available credit limit(s) the order is deemed acceptable, then the order is placed in the order book. Similarly, if a credit limit update is received by the matching engine, for example, an increase in daily limit for a client or a particular institution for a specific security or for a specific market, then the matching engine updates its internal credit limits.
A problem with using such a method is that if there are more than one matching engines within a market or within a venue, then two separate credit pools exist and the credit may become fragmented. For example, consider a relatively straightforward scenario in which there are two matching engines with four securities as shown in the chart below:
Matching Engine 1Matching Engine 2Security 1Security 3Security 2Security 4Credit Pool 1Credit Pool 2Each matching engine would have its own credit pool for the given institution. Matching Engine 1 would have a credit pool that covers only Securities 1 and 2, whereas Matching Engine 2 would have a credit pool that covers only Securities 3 and 4 for the institution. Thus, the institution would have no ability to set a single credit limit to encompass all four securities being traded at the same time since the credit is fragmented across the various matching engines.
A second method is to centralize processing for the credit limits, to address these problems. As illustrated in FIG. 3, credit processing is centralized in a centralized credit engine that is run with one or more credit pools based on client requirements or configuration requirements. A matching engine or transaction engine may query a central location for credit during its order book matching process. Thus, as each order is updated to an order book, a centralized credit approach may query a central location to determine whether credit is available (i.e., whether the current order would exceed the pre-set credit limit) for the order being processed. Then, during the order book matching process, each matching engine connects to the centralized credit engine to query whether credit is available. The centralized credit approach guarantees that there is no credit leak within the market or venue, and that the user has no exposure that exceeds the credit limit that has been set.
A problem with this approach is that since order book transactions are linear (or sequential), memory resources of the centralized credit engine would be blocked by a first process while a second process has to wait. Thus, since Matching Engine 2 must wait for processing performed by a centralized credit engine on behalf of Matching Engine 1, latency is added for the system since the centralized credit engine processor and memory are being used for an order being processed for Matching Engine 1. However, such a system prevents credit leak within the market or venue, and the user is guaranteed to have no exposure over the credit limit that has been set. For example, consider the following chart, in which a user has two orders in the venue as follows:
Order 1Order 2Buy 10 million units ofBuy 10 million units ofSecurity 1 at price 10Security 6 at price 10Assuming that sufficient sell orders are available on the venue at the moment to fulfill the above two buy orders, and thus that the matching engines can perform the order processing, the user would then have bought 10 million shares each of Security 1 and Security 6. However, assuming that the user requests to have a credit limit set of 15 million units on the venue (that is, the user, for example, an institution, sets a credit limit of 15 million units globally for the venue), the centralized credit engine would maintain such a credit limit for the user. When the orders are submitted to the market starting with order book Security 1, the following steps would take place:    1. Order 1 goes to matching engine 1.    2. Matching engine 1's security 1 order book is locked and the order is placed in the order book.    3. Matching engine 1 runs its matching algorithm. During the executing of the matching algorithm, the matching engine 1 determines that a trade can happen.    4. Matching engine 1 connects out to the credit engine.    5. Credit engine receives the request to check credit on the tradable order. Credit engine locks its credit pool.    6. Credit engine determines whether the trade can happen. Credit engine updates its credit limit to 10 mm used and responds to matching engine 1 that the trade can proceed.    7. Credit engine unlocks its credit pool.    8. Matching engine 1 creates a trade and removes the matching orders from the order book.    9. Matching engine 1 unlocks its order book for security 1.    10. Order 2 goes to matching engine 2.    11. Matching engine 2's security 6 order book is locked and the order is placed in the order book.    12. Matching engine 2 runs its matching algorithm. During the executing of the matching algorithm, matching engine 2 determines that a trade can proceed.    13. Matching engine 2 connects out to the credit engine.    14. Credit engine receives the request to check credit on the tradable order. Credit engine locks its credit pool.    15. Credit engine determines whether the trade can be allowed. Credit engine determines that only 5 mm can be used for the user (as limit is 15 mm, and 10 mm is already used). Credit engine updates its credit limit to 15 mm used and responds to matching engine 2 that the trade can proceed only for 5 mm.    16. Credit engine unlocks its credit pool.    17. Matching engine 2 creates a trade for 5 mm and leaves the other 5 mm open. It also removes the matching orders from the order book.    18. Matching engine 2 unlocks its order book for security 6.
Thus, a disadvantage of this centralized model is that latency is introduced by the checking and updating of the centralized credit available for each order at the central credit engine. For each order, the memory of the central credit engine must be queried to determine the available credit limit, and if an order is executed, then the memory must be updated. Writing to computer memory takes longer than computer processing that does not entail memory updates. While this check is occurring for an order for a first matching engine, the remaining matching engines must wait with its order book updates because the centralized credit locks itself or at least locks a computer memory resource thereof, until the first transaction is complete.